1. Field of the Invention
The present invention generally relates to logically partitioned computer systems and more particularly to applying concurrent updates to a logical partitioning operating system.
2. Description of the Related Art
In a computing environment, parallel processing generally refers to performing multiple computing tasks in parallel. Traditionally, parallel processing required multiple computer systems, with the resources of each computer system dedicated to a specific task, or allocated to perform a portion of a common task. However, recent advances in computer hardware and software technologies have resulted in single computer systems capable of highly complex parallel processing, by logically partitioning the system resources to different tasks. In a logically partitioned computer system, available system resources are allocated among multiple logical partitions, each designed to appear to operate independently of the other. Management of the allocation of resources among logical partitions is typically accomplished via a layer of software components, commonly referred to as a partition manager.
An objective of the partition manager is to allow each logical partition to independently run software (e.g., operating systems and operating system-specific applications), typically developed to run on a dedicated computer system, with little or no modification. For example, one logical partition may be running a first operating system, such as IBM's OS/400, a second logical partition may be running a second operating system, such as IBM's AIX, while a third logical partition may be running a third operating system, such as Linux. By providing the ability to run multiple operating systems on the same computer system, a logically partitioned system may provide a user with a greater degree of freedom in choosing application programs best suited to the user's needs with little or no regard to the operating system for which an application program was written.
Like any other layer of software in the system, the partition manager may require updates to fix problems that occur in the field (e.g., at a customer location), or to provide product enhancements (e.g., support of additional features). In some cases, to ensure no component accesses a portion of code as it is being updated, which may result in unpredictable behavior, a developer may require a system initial program load (IPL) to apply the update.
An IPL (also referred to as a system boot) generally refers to the process of taking a system from a powered-off or non-running state to the point of loading operating system specific code. This process could include running various tests on components and, in a multi-processor system all functioning processors would go through the IPL process, which may require a significant amount of time. Considering the fact that a logically partitioned system may include several partitions, requiring a system IPL to apply an update to partition manager code may represent unacceptable downtime for the several partitions. Therefore, it is generally desirable that an update to partition manager code be applied while the system is running (i.e., as a concurrent update).
However, a number of difficulties arise when applying a concurrent update, due to the fact that processors or tasks may be running or “executing in” code that may be replaced by the update. According to a conventional approach, an old copy of the code being updated may be maintained to accommodate processors or tasks that were running in the portion of the code being updated (at the time the update is applied). For example, processors executing in the code to be replaced by the update may be interrupted in order to apply the update. After the concurrent update is complete, the processors may be released to resume execution from their interrupted points in the old copy of the code. As another example, when the update is applied, some tasks that were executing in the code may be blocked on a wait object (e.g., a queue, gate, or semaphore). The blocked task will have saved addresses of code that may be replaced by the update. Therefore, at some point after the concurrent update has been applied, the blocked task will complete its wait and return to executing in the old copy of code.
Thus, a developer designing a concurrent update has to carefully consider the implications of a processor or task executing in the old copy of the code while another processor or task is executing in the updated version of the code. However, a developer may have difficulty in anticipating the number of complex interactions that may occur between different components executing in different versions of the partition manager code. Determining these interactions may require extensive testing and it may be difficult or impossible to recreate some of the complex interactions when testing the concurrent update. As a result, some interactions may be complex enough that they prohibit an update from being applied concurrently.
Accordingly, there is a need for an improved method and system for applying an update to a portion of partition manager code that does not require an IPL.